1. Field of the Invention
The present invention relates to an AAA (Authentication, Authorization and Accounting) system, and more particularly to a RADIUS (Remote Authentication Dial-In User Service) protocol.
2. Description of the Related Art
A RADIUS (Remote Authentication Dial-In User Service) protocol is widely used as an industrial standard protocol of an AAA (Authentication, Authorization and Accounting) system performing mobile subscriber authentication for mobile Internet services, authorization verification and accounting information management for the sake of safe mobile Internet services. Such a RADIUS protocol was developed in the mid-1990s to provide NAS (Network Access Service) equipment, which is made by LIVINGSTON ENTERPRISES, Inc. owned by LUCENT TECHNOLOGIES, Inc., with authentication and accounting related services. As major characteristics, the RADIUS protocol uses a UDP (User Datagram Protocol) with a transport layer and conforms to a request/response scheme based on a client-server structure. Further, the authentication in the RADIUS protocol is accomplished using a prescribed shared secret key, which is not transferred over a network between a RADIUS client and a RADIUS server. Furthermore, the RADIUS protocol can use a variety of authentication protocols such as a PAP (Password Authentication Protocol) being an authentication protocol in a PPP (Point-to-Point Protocol), and a CHAP (Challenge Handshake Authentication Protocol) and the RADIUS protocol can be extended by the addition of new attributes.
A RADIUS system is based on a RADIUS protocol. For convenience, only one RADIUS client and one user are used in this RADIUS system example, but the RADIUS system includes a plurality of RADIUS clients and a plurality of users in practice. The RADIUS client as the NAS equipment connected to the user is connected to one of a plurality of RADIUS servers by the RADIUS protocol. The RADIUS servers are connected to a centralized DB (database) as a DB for the user According to the client-server structure based on the UDP of the RADIUS protocol in such a RADIUS system, if the RADIUS client requests an authentication and accounting process to one of the RADIUS servers, a corresponding RADIUS server sends a response to the request from the RADIUS client. At this time, a primary server, a secondary server and alternative servers among the RADIUS servers are designated to the RADIUS client. First, the RADIUS client transmits a request message having a packet format based on the RADIUS protocol to a RADIUS server designated as the primary server. Then, if the RADIUS client does not receive a response message from the RADIUS server, the RADIUS client re-transmits the request message a predetermined number of times until the RADIUS client receives the response message from the RADIUS server. Further, if the RADIUS client does not receive the response message from the primary server in spite of re-transmitting the request message the predetermined number of times, the RADIUS client transmits the request message to a RADIUS server designated as the secondary server in the same way as described above instead of the RADIUS server designated as the primary server. Furthermore, if the RADIUS client does not receive the response message from the secondary server in spite of re-transmitting the request message the predetermined number of times, the RADIUS client transmits the request message to one of RADIUS servers designated as the alternative servers in the same way as described above instead of the RADIUS server designated as the secondary server. Here, the alternative servers are sequentially selected, respectively.
In the client-server structure based on the UDP of the RADIUS protocol, the RADIUS server only performs a response function to the request of a RADIUS client. Conventionally, the RADIUS client and servers cannot know an operating state of the RADIUS server and an operating state of the RADIUS client, respectively. Now, there is not a mechanism in which either the RADIUS client or the RADIUS server can control a flow of the RADIUS protocol.
Accordingly, if a request message transmission in the RADIUS client is timed out, the RADIUS client cannot identify whether the time-out results from a network failure or a software error of the RADIUS server or whether the time-out results from insufficient process capability of the RADIUS server caused by the congestion of request messages. In this case, the RADIUS client re-transmits the request message the predetermined number of times to the RADIUS server regardless of a cause of the time-out. Because the RADIUS client tries to re-transmit the request message to other RADIUS servers until the RADIUS client receives the response message, the RADIUS client needs a lot of time to receive the request message from an available RADIUS server. Further, because the RADIUS client may re-transmit the request message to a particular RADIUS server whose process capability is insufficient, the re-transmission of the request message burdens the particular RADIUS server with a heavy load.